Nydus|容器镜像基础

文&＃xff5c;唐斌

字节跳动基础架构研发工程师

Nydus 与 Nydus snapshotter 社区贡献者&＃xff0c;专注存储&＃xff0c;云原生技术。

本文 6964 字 阅读 15 分钟

1 Nydus

1.1 存在的问题

对于容器镜像使用者

问题一&＃xff1a; 启动容器慢&＃xff1a;容器启动慢的情况普遍发生在当用户启动一个很大的容器镜像时&＃xff0c;由于在容器准备阶段需要三步&＃xff08;以 overlayfs 为例&＃xff09;&＃xff1a;

- 下载镜像&＃xff1b;

- 解压镜像&＃xff1b;

- 使用 overlayfs 将容器可写层和镜像中的只读层聚合起来提供容器运行环境。

其中&＃xff0c;下载镜像阶段需要下载整个镜像文件&＃xff0c;不能实现文件数据按需加载。再加上下载镜像本身受限于网络带宽&＃xff0c;当容器镜像达到 GB 级别时&＃xff0c;下载时间会较长&＃xff0c;破坏了容器原本优秀的用户体验。

问题二&＃xff1a; 较高的本地存储成本&＃xff1a;不同镜像之间可以共享的最小单位是镜像中的层&＃xff0c;缺点之一是重复数据的处理效率较低。

原因如下&＃xff1a;

- 首先&＃xff0c;层内部存在重复的数据&＃xff1b;

- 其次&＃xff0c;层与层之间可能存在大量重复的数据&＃xff0c;即使有微小的差别&＃xff0c;也会被作为不同的层&＃xff1b;

- 再次&＃xff0c;根据 OCI imagespec 对删除文件和 hardlink 的设计&＃xff0c;镜像内部已经被上层删除的文件可能仍然存在于下层&＃xff0c;并包含在镜像中。

对于镜像提供者

这里的提供者主要指容器服务的镜像中心。

问题一&＃xff1a; 巨大的存储资源浪费。

- 存在大量相似镜像&＃xff0c;造成这种情况有两个原因&＃xff1a;

• 首先&＃xff0c;上面提到的层的缺点&＃xff0c;导致在容器镜像中心存在许多相似镜像&＃xff1b;

• 其次&＃xff0c;OCI image 使用了 tar&＃43;gzip 格式来表示镜像中的层&＃xff0c;而 tar 格式并不区分 tar archive entries ordering&＃xff0c;这带来一个问题&＃xff0c;如果用户在不同机器上 build 同一个镜像&＃xff0c;最终可能会因为使用了不同的文件系统而得到不同的镜像&＃xff0c;用户上传之后&＃xff0c;镜像中心中会存在若干不同镜像的实质内容是完全相同的情况。

- 镜像去重效率低

虽然镜像中心有垃圾回收机制来实现去重功能&＃xff0c;但其仍然以层为单位&＃xff0c;所以只能在有完全相同 hash value 的层之间去重。

问题二&＃xff1a; 云原生软件供应链带来的新需求。

随着时间推移&＃xff0c;和软件供应链一起发展的还有对软件供应链环节的多样性攻击手段。安全防护是软件供应链中非常重要的组成&＃xff0c;不光体现在对软件本身的安全增强&＃xff0c;也体现在对供应链的安全增强。因为应用运行环境被前置到了容器镜像中&＃xff0c;所以对容器镜像的安全&＃xff0c;包括对镜像的漏洞扫描和签名成为了容器服务提供者的必要能力。

OCI 镜像规范的缺陷

主要的缺陷有两点&＃xff1a;

- tar 格式标准

• tar 格式并不区分 tar archive entries ordering&＃xff0c;这带来一个问题&＃xff0c;即如果用户在不同机器上 &＃xff1b;build 同一个镜像&＃xff0c;最终可能会因为使用了不同的文件系统而得到不同的镜像&＃xff0c;比如在文件系统 A 上的 order 是 foo 在 bar 之前进入 tar &＃xff0c;在文件系统 B 上的 order 是 bar 在 foo 之前进入tar &＃xff0c;那么这两个镜像是不同的&＃xff1b;

• 当 tar 被 gzip 压缩过之后不支持 seek &＃xff0c;导致运行之前必须先下载并解压 targz 的 image layers&＃xff0c;而不能实现文件数据按需加载。

- 以层为镜像的基本单位

• 内容冗余&＃xff1a;不同层之间相同信息在传输和存储时都是冗余内容&＃xff0c;在不读取内容的时候无法判断到这些冗余的存在&＃xff1b;

• 无法并行&＃xff1a;每一层是一个整体&＃xff0c;对同一个层既无法并行传输&＃xff0c;也不能并行提取&＃xff1b;

• 无法进行小块数据的校验&＃xff0c;只有完整的层下载完成之后&＃xff0c;才能对整个层的数据做完整性校验&＃xff1b;

• 其他一些问题&＃xff1a;比如&＃xff0c;跨层数据删除难以完美处理。

1.2 Nydus 基础

在容器的生产实践中&＃xff0c;偏小的容器镜像能够很快部署启动。当应用的镜像达到 GB 级以上的时候&＃xff0c;在节点上下载镜像通常会消耗大量的时间。Dragonfly 通过引入 P2P 网络有效地提升了容器镜像大规模分发的效率。然而&＃xff0c;用户必须等待镜像数据完整下载到本地&＃xff0c;然后才能创建自己的容器。

Nydus 是在最新的 OCI Image-Spec 基础之上设计的容器镜像加速服务&＃xff0c;重新设计了镜像格式和底层文件系统&＃xff0c;从而加速容器启动速度&＃xff0c;提高大规模集群中的容器启动成功率。Nydus 由阿里云和蚂蚁集团的工程师合作开发&＃xff0c;并大规模部署在内部的 生产环境中。

Nydus 优化了现有的 OCI 镜像标准格式&＃xff0c;并以此设计了一个用户态的文件系统。通过这些优化&＃xff0c;Nydus 能够提供这些特性&＃xff1a;

• 容器镜像按需下载&＃xff0c;用户不再需要下载完整镜像就能启动容器

• 块级别的镜像数据去重&＃xff0c;最大限度为用户节省存储资源

• 镜像只有最终可用的数据&＃xff0c;不需要保存和下载过期数据

• 端到端的数据一致性校验&＃xff0c;为用户提供更好的数据保护

• 兼容 OCI 分发标准和 artifacts 标准&＃xff0c;开箱即可用

支持不同的镜像存储后端&＃xff0c;镜像数据不只可以存放在镜像仓库&＃xff0c;还可以放到 NAS 或者类似 S3 的对象存储上

• 与 Dragonfly 的良好集成

1.3 Nydus 架构

Nydus 的架构主要包含两部分内容&＃xff1a;

- 新的镜像格式&＃xff08;Rafs&＃xff09;

- 负责解析容器镜像的 FUSE 用户态文件系统进程

Nydus 兼容多种文件系统&＃xff0c;能够解析 FUSE 和 virtiofs 协议来支持传统的 runc 容器、 Kata容器。对于存储后端&＃xff0c;支持使用容器仓库&＃xff08; Registery &＃xff09;、OSS 对象存储 、NAS、Dragonfly 的超级节点和 Peer 节点作为 Nydus 的镜像数据存储后端。此外&＃xff0c;为了加速启动速度&＃xff0c;Nydus 还可以配置一个本地缓存&＃xff0c;避免每次启动容器时都从远端数据源拉取数据。

1.4 Nydus 特性

容器启动速度变快

用户部署了 Nydus 镜像服务后&＃xff0c;由于使用了按需加载镜像数据的特性&＃xff0c;容器的启动时间明显缩短。在官网的测试数据中&＃xff0c;Nydus 能够把常见镜像的启动时间&＃xff0c;从数分钟缩短到数秒钟。理论上来说&＃xff0c;容器镜像越大&＃xff0c;Nydus 体现出来的效果越明显。

提供运行时数据一致校验

在传统的镜像中&＃xff0c;镜像数据会先被解压到本地文件系统&＃xff0c;再由容器应用去访问使用。解压前&＃xff0c;镜像数据是完整校验的。但是解压之后&＃xff0c;镜像数据不再能够被校验。这带来的一个问题就是&＃xff0c;如果解压后的镜像数据被无意或者恶意地修改&＃xff0c; 用户是无法感知的。而 Nydus 镜像不会被解压到本地&＃xff0c;同时可以对每一次数据访问进行校验&＃xff0c;如果数据被篡改&＃xff0c;则可以从远端数据源重新拉取。

从图中可以看出&＃xff0c;对容器镜像数据进行运行时一致性校验是通过对每个数据块计算 SHA 256 实现的&＃xff0c;这得益于 Nydus 采用分块的方式管理镜像数据。如果在镜像文件非常大的时候&＃xff0c;对整个镜像文件计算哈希值非常不现实。

1.5 Nydus 镜像格式&＃xff1a;RAFS

RAFS 是对 EROFS 文件系统的增强&＃xff0c;拓展在云原生场景下的能力&＃xff0c;使其适应容器镜像存储场景。RAFS v6 是内核态的容器镜像格式&＃xff0c;除了将镜像格式下沉到内核态&＃xff0c;还在镜像格式上进行了一系列优化&＃xff0c;例如块对齐、更加精简的元数据等。

RAFS v6 镜像格式

1.6 Nydus -snapshotter

Nydus snapshotter 是 containerd 的一个外部插件&＃xff0c;使得 containerd 能够使用 Nydus 镜像加速服务。在 containerd 中&＃xff0c; snapshot 的工作是给容器提供 rootfs&＃xff0c;Nydus snapshotter 实现了 containerd 的 snapshot 的接口&＃xff0c;使得 containerd 可以通过 Nydus 准备 rootfs 以启动容器。由于 nydus-snapshotter 实现了按需加载的特性&＃xff0c;在 containerd 启动容器时&＃xff0c;只需要根据容器镜像的元数据信息准备 rootfs &＃xff0c;部分目录对应的数据并未存储在本地&＃xff0c;当在容器中访问到&＃xff08;本地访问未命中&＃xff09;这部分数据时&＃xff0c;通过 Nydusd 从镜像 registry 拉取对应数据内容。

02 FUSE

用户态文件系统&＃xff08; filesystem in userspace&＃xff0c; 简称 FUSE &＃xff09;使得用户无需修改内核代码就能创建自定义的文件系统。FUSRE 催生了著名的 fuse-overlayfs&＃xff0c;其在 rootless 容器化中扮演重要的角色。

用户态文件系统并不完全在用户态实现&＃xff0c;由两部分组成&＃xff1a;内核模块和用户态进程。

• 内核模块&＃xff1a;文件系统数据流程的功能实现&＃xff0c;负责截获文件访问请求和返回用户态进程处理请求的结果

• 用户态进程&＃xff1a;负责处理具体的数据请求&＃xff0c;对应处理函数由内核模块触发

FUSE 的工作流程如下图&＃xff1a;

其中&＃xff0c;fuse_user 是运行在用户态的文件系统进程&＃xff0c;该程序会在启动时注册实现的数据请求处理接口&＃xff0c;如 ls 、cd 、mkdir 等&＃xff0c;同时&＃xff0c;程序在某个路径挂载 fuse 文件系统 /tmp/fuse_fs &＃xff0c;当对 /tmp/fuse_fs 执行相关操作时&＃xff1a;

• 请求会经过 VFS&＃xff08;虚拟文件系统&＃xff09; 到达 fuse 的内核模块

• 内核模块根据请求类型&＃xff0c;调用用户态进程注册的函数

• 当程序完成对请求的处理后&＃xff0c;将结果通过 VFS 返回给系统调用

03 Containerd

Containerd 最开始是 Docker Engine 中的一部分&＃xff0c;后来&＃xff0c;containerd 被分离出来作为独立的开源项目&＃xff0c;目标是提供更开放、稳定的容器运行基础设施。分离出来的 containerd 将具有更多的功能&＃xff0c;涵盖整个容器运行时管理的所有需求。

Containerd 是一个行业标准的容器运行时&＃xff0c;强调简单性、健壮性和可移植性&＃xff0c;可以作为守护进程运行在系统中。

Containerd 的功能主要包括以下内容&＃xff1a;

• 管理容器的生命周期&＃xff08;从创建容器到销毁容器&＃xff09;

• 拉取/推送容器镜像

• 存储管理&＃xff08;管理镜像及容器数据的存储&＃xff09;

• 调用 runc 运行容器&＃xff08;与 runc 等容器运行时交互&＃xff09;

• 管理容器网络接口及网络

Containerd 采用 C/S 架构&＃xff0c;服务端通过 unix domain socket 暴露低层 gRPC 接口&＃xff0c;客户端通过这些 gRPC 接口管理节点上的容器&＃xff0c;containerd 负责管理容器的镜像、生命周期、网络和存储&＃xff0c;实际运行容器是由容器运行时&＃xff08;runc 是其中一种&＃xff09;完成。

Containerd 将系统划分成不同的组件&＃xff0c;每个组件由一个或多个模块协作完成&＃xff08;Core 部分&＃xff09;&＃xff0c;不同模块都以插件的形式集成到 containerd 中&＃xff0c;插件之间相互依赖。

Containerd 的组件可以分成三类&＃xff1a;Storage、Metadata 和 Runtimes&＃xff0c;snapshot 属于 Storage 组件中的一个插件&＃xff0c;用来管理容器镜像的文件系统快照&＃xff0c;镜像中的每一层都会被解压成文件系统快照。在使用 Nydus 的 containerd 环境中&＃xff0c;Nydus-snapshotter 负责完成这部分工作。

04 Erofs &＃43; fsache

Erofs over fscache 基本概念

Erofs over fscache 是 Linux 内核原生的镜像按需加载特性&＃xff0c;于 5.19 版本合入 Linux 内核主线。

已有的用户态方案会涉及频繁的内核态/用户态上下文切换&＃xff0c;以及内核态/用户态之间的内存拷贝&＃xff0c;从而造成性能瓶颈。这一问题在容器镜像已经全部下载到本地的时候尤其突出&＃xff0c;容器运行过程中涉及的文件访问&＃xff0c;都会陷出到用户态的服务进程。

事实上我们可以将按需加载的

&＃xff08;1&＃xff09;缓存管理和 

&＃xff08;2&＃xff09;缓存未命中的时候通过各种途径 (例如网络) 获取数据&＃xff0c;这两个操作解耦开。缓存管理可以下沉到内核态执行&＃xff0c;这样当镜像在本地 ready 的时候&＃xff0c;就可以避免内核态/用户态上下文的切换。而这也正是 erofs over fscache 技术的价值所在。

fscache/cachefiles  (以下统称 fscache ) 是 Linux 系统中相对成熟的文件缓存方案&＃xff0c;广泛应用于网络文件系统&＃xff0c;erofs over fscache 技术使得 fsache 能够支持 erofs 的按需加载特性。

容器在访问容器镜像的时候&＃xff0c;fscache 会检查当前请求的数据是否已经缓存&＃xff0c;如果缓存命中 ( cache hit )&＃xff0c;那么直接从缓存文件读取数据。这一过程全程处于内核态之中&＃xff0c;并不会陷出到用户态。

缓存未命中 ( cache miss )时 需要通知用户态的 Nydusd 进程以处理这一访问请求&＃xff0c;此时容器进程会陷入睡眠等待状态&＃xff1b;Nydusd 通过网络从远端获取数据&＃xff0c;通过 fscache 将这些数据写入对应的缓存文件&＃xff0c;之后通知之前陷入睡眠等待状态的进程该请求已经处理完成&＃xff1b;之后容器进程即可从缓存文件读取到数据。

Erofs over fscache 优势

- 异步预取

容器创建之后&＃xff0c;当容器进程尚未触发按需加载 (cache miss) 的时候&＃xff0c;用户态的 Nydusd 就可以开始从网络下载数据并写入缓存文件&＃xff0c;之后当容器访问的文件位置恰好处于预取范围内的时候&＃xff0c;就会触发 cache hit 直接从缓存文件读取数据&＃xff0c;而不会再陷出到用户态。用户态方案则无法实现该优化。

- 网络 IO 优化

当触发按需加载 (cache miss) 时&＃xff0c;Nydusd 可以一次性从网络下载比当前实际请求的数据量更多的数据&＃xff0c;并将下载的数据写入缓存文件。例如容器访问 4K 数据触发的 cache miss&＃xff0c;而 Nydusd 实际一次性下载 1MB 数据&＃xff0c;以减小单位文件大小的网络传输延时。之后容器访问接下来的这 1MB 数据的时候&＃xff0c;就不必再陷出到用户态。

用户态方案则无法实现该优化&＃xff0c;因为即使触发 cache miss 的时候&＃xff0c;用户态的服务进程同样实现了该优化&＃xff0c;下一次容器访问位于读放大范围内的文件数据的时候&＃xff0c;同样会陷出到用户态。

- 更佳的性能表现

当镜像数据已经全部下载到本地的时候 (即不考虑按需加载的影响)&＃xff0c; erofs over fscache 的性能表现显著优于用户态方案&＃xff0c;同时与原生文件系统的性能相近&＃xff0c;从而实现与原生容器镜像方案 (未实现按需加载) 相近的性能表现。

05 环境安装

nerdctl 安装

# git clone https://github.com/rootless-containers/rootlesskit.git
# cd rootlesskit
# make && sudo make install
wget https://github.com/containerd/nerdctl/releases/download/v0.22.2/nerdctl-full-0.22.2-linux-amd64.tar.gz
sudo tar -zxvf nerdctl-full-0.22.2-linux-amd64.tar.gz -C /usr/local
sudo systemctl enable --now containerd
sudo systemctl enable --now buildkit
# sudo apt-get install uidmap -y
# containerd-rootless-setuptool.sh install
sudo nerdctl version # 需要使用sudo&＃xff0c;不然会提示安装 rootless


Nydus 安装

装主要的3个工具&＃xff08;也可以直接下载所有工具的二进制文件&＃xff0c;编译安装时默认没有没有 Nydusify &＃xff09;&＃xff1a;

- nydusify 将 OCI 格式的容器镜像转换为 Nydus 格式&＃xff08; RAFS &＃xff09;容器镜像的工具。

- nydus-image将解压后的容器镜像转换为 Nydus 格式镜像的工具。

- nydusd 解析 Nydus 格式镜像并提供 FUSE 挂载点以供容器访问的守护程序。nydusd 也可以用作 virtiofs 后端&＃xff0c;使得 Guest 可以访问 Host 的文件。

git clone https://github.com/dragonflyoss/image-service.git
cd image-service
make && make install
# 默认没有安装 nydusify
wget https://github.com/dragonflyoss/image-service/releases/download/v2.1.0-rc.1/nydus-static-v2.1.0-rc.1-linux-amd64.tgz
mkdir nydus-static
tar -zxvf nydus-static-v2.1.0-rc.1-linux-amd64.tgz -C nydus-static
sudo cp nydus-static/nydusify /usr/local/bin
sudo cp nydus-static/nydus-overlayfs /usr/local/bin
nydus-image --version
nydusify --version
nydusd --version


安装 Nydus-snapshotter

git clone github.com/containerd/nydus-snapshotter.git
cd nydus-snapshotter
make && make install
sudo systemctl enable nydus-snapshotter
sudo systemctl start nydus-snapshotter
systemctl status nydus-snapshotter


Nydus-snapshotter 以 service 的形式运行 /usr/local/bin/containerd-nydus-grpc 可执行文件&＃xff0c;配置信息位于 /etc/nydus/config.json 文件。

默认 address 位置&＃xff1a;

/run/containerd-nydus/containerd-nydus-grpc.sock

默认工作目录&＃xff1a;

/var/lib/containerd-nydus-grpc

默认缓存目录&＃xff1a;

/var/lib/containerd-nydus-grpc/cache

部署本地镜像仓库&＃xff08;测试用&＃xff09;

# sudo docker run -d -p 5000:5000 \
# --restart&＃61;always \
# --name registry \
# -v /var/lib/registry:/var/lib/registry \
# -d registry
sudo docker run -d --name&＃61;registry --restart&＃61;always -p 5000:5000 registry
sudo docker logs registry -f


将 OCI 格式的镜像转换为 RAFS 格式镜像

sudo nydusify convert \
--nydus-image $(which nydus-image) \
--source ubuntu:16.04 \
--target localhost:5000/ubuntu:16.04-nydus


Nydusify 基本命令&＃xff1a;

转换后的镜像层文件位于当前目录下的 tmp 文件夹&＃xff1a;

sudo tree tmp -L 4


将 OCI 标准的镜像格式转换为 Nydus 使用的 RAFS 镜像格式后&＃xff0c;可以使用 Nydusd 解析并提供 fuse 挂载点供容器使用。编写配置文件 registry.json&＃xff0c;使得 Nydus 使用 容器镜像 registry &＃xff08;已经搭建本地容器镜像 register 用于测试&＃xff09;作为存储后端。

{
"device": {
"backend": {
"type": "registry",
"config": {
"scheme": "http",
"host": "localhost:5000",
"repo": "ubuntu"
}
},
"digest_validate": false
},
"mode": "direct"
}


挂载  RAFS 镜像 为 fuse 挂载点&＃xff0c;--bootstrap 参数传递位于 tmp/bootstraps 下的文件路径&＃xff1a;

sudo nydusd \
--config ./registry.json \
--mountpoint /mnt \
--bootstrap ./tmp/bootstraps/4-sha256:fb15d46c38dcd1ea0b1990006c3366ecd10c79d374f341687eb2cb23a2c8672e \
--log-level info


查看挂载情况&＃xff1a;

输出日志信息&＃xff1a;

除了使用 Nydusify 直接将 OCI 标准格式镜像转换为 Nydus 格式镜像&＃xff0c;Nydus-image 工具也支持直接对已经解压的 OCI 容器镜像文件层转换为 Nydus 格式镜像。

&＃xff08;1&＃xff09;获取 OCI 镜像元数据信息&＃xff1a;

docker pull ubuntu:16.04
sudo docker inspect -f "{{json .GraphDriver }}" ubuntu:16.04 | jq .


Docker 使用 overlay2 存储驱动&＃xff0c;通过所需的 lowerdir 、upperdir 、merged 和 workdir 结构自动创建 overlay 挂载点。

对于 Nydus 来说&＃xff0c;目录树&＃xff08;通常是一个镜像层&＃xff09;由两部分组成&＃xff1a;

• bootstrap&＃xff1a;存储目录的文件系统元数据信息

• blob&＃xff1a;存储目录中的所有文件数据

&＃xff08;2&＃xff09;建立生成 Nydus 镜像的目录&＃xff1a;

mkdir -p nydus-image/{blobs,layer1,layer2,layer3,layer4}


&＃xff08;3&＃xff09;转换最底层的镜像层&＃xff1a;

sudo nydus-image create \
--bootstrap ./nydus-image/layer1/bootstrap \
--blob-dir ./nydus-image/blobs \
--compressor none /var/lib/docker/overlay2/78f2b3506072c95ca3929a0a797c1819e8966b8bbf5ce8427b671296ca1ad35a/diff
tree -L 2 ./nydus-image


&＃xff08;4&＃xff09;转换第 2 底层镜像层&＃xff0c;--parent-bootstrap 指父层&＃xff0c;即刚才转换好的镜像层&＃xff1a;

sudo nydus-image create \
--parent-bootstrap ./nydus-image/layer1/bootstrap \
--bootstrap ./nydus-image/layer2/bootstrap \
--blob-dir ./nydus-image/blobs \
--compressor none /var/lib/docker/overlay2/373ea430abb0edd549583f949ec8259806d9eb7d0a0416ec1494d2fc7efeeedc/diff


&＃xff08;5&＃xff09;转换第 3 层和第 4 层&＃xff0c;每次都需要指定 --parent-bootstrap 为上一次生成的镜像层&＃xff1a;

sudo nydus-image create \
--parent-bootstrap ./nydus-image/layer2/bootstrap \
--bootstrap ./nydus-image/layer3/bootstrap \
--blob-dir ./nydus-image/blobs \
--compressor none /var/lib/docker/overlay2/05424b8c067c59368c11ad5674d68d95365e87487bdf10e3d9842b1016583369/diff
sudo nydus-image create \
--parent-bootstrap ./nydus-image/layer3/bootstrap \
--bootstrap ./nydus-image/layer4/bootstrap \
--blob-dir ./nydus-image/blobs \
--compressor none /var/lib/docker/overlay2/942c712e7276be5bde4fb7b30f72583c4a9cf0b2aaa14215cd690daf893a630e/diff


将 Nydus 镜像挂载到目录&＃xff1a;

sudo nydusd \
--config ./localfs.json \
--mountpoint /mnt \
--bootstrap ./nydus-image/layer4/bootstrap \
--log-level info


其中&＃xff0c; localfs.json 文件的内容为&＃xff1a;

{
"device": {
"backend": {
"type": "localfs",
"config": {
"dir": "//nydus-image/blobs"
}
}
},
"mode": "direct"
}


Dir 为生成的 Nydus 镜像文件中 blobs 目录的绝对路径。

06 通过 Nydus&＃43;snapshotter 启动容器

添加配置文件

Nydus 提供了 containerd 远程快照管理工具 containerd-nydus-grpc 用于准备 Nydus 镜像格式的容器 rootfs &＃xff0c;首先将 Nydusd 配置保存到  /etc/nydus/config.json 文件。

sudo tee /etc/nydus/config.json > /dev/null <{
"device": {
"backend": {
"type": "registry",
"config": {
"scheme": "http",
"skip_verify": false,
"timeout": 5,
"connect_timeout": 5,
"retry_limit": 2,
"auth": ""
}
},
"cache": {
"type": "blobcache",
"config": {
"work_dir": "cache"
}
}
},
"mode": "direct",
"digest_validate": false,
"iostats_files": false,
"enable_xattr": true,
"fs_prefetch": {
"enable": true,
"threads_count": 4
}
}
EOF


containerd-nydus-grpc 会自动从 $HOME/.docker/config.json 中读取 docker login auth &＃xff0c;如果不想使用这个值&＃xff0c;需要直接替换配置文件中的内容。

直接从终端启动 containerd-nydus-grpc&＃xff0c;如果已经通过 containerd-nydus-grpc service 启动&＃xff0c;则可以跳过此步骤&＃xff1a;

sudo /usr/local/bin/containerd-nydus-grpc \
--config-path /etc/nydus/config.json \
--shared-daemon \
--log-level info \
--root /var/lib/containerd/io.containerd.snapshotter.v1.nydus \
--cache-dir /var/lib/nydus/cache \
--address /run/containerd-nydus/containerd-nydus-grpc.sock \
--nydusd-path /usr/local/bin/nydusd \
--nydusimg-path /usr/local/bin/nydus-image \
--log-to-stdout


修改 containerd 配置文件

proxy_plugins.nydus 的 address 和 containerd-nydus-grpc 的对应。

sudo tee -a /etc/containerd/config.toml <[proxy_plugins]
[proxy_plugins.nydus]
type &＃61; "snapshot"
address &＃61; "/run/containerd-nydus/containerd-nydus-grpc.sock"
[plugins.cri]
[plugins.cri.containerd]
snapshotter &＃61; "nydus"
disable_snapshot_annotations &＃61; false
EOF
sudo systemctl restart containerd
sudo ctr -a /run/containerd/containerd.sock plugin ls | grep nydus


通过 Nydus 启动容器

# 转换镜像并上传到本地 registry
sudo nydusify convert --nydus-image /usr/local/bin/nydus-image --source ubuntu --target localhost:5000/ubuntu-nydus
sudo nerdctl --snapshotter nydus pull localhost:5000/ubuntu-nydus:latest
sudo nerdctl --snapshotter nydus run --rm -it localhost:5000/ubuntu-nydus:latest bash


重启主机之后启动环境

sudo systemctl restart nydus-snapshotter
sudo systemctl restart containerd
sudo docker rm -f registry
sudo docker run -d --name&＃61;registry --restart&＃61;always -p 5000:5000 registry && sudo docker logs registry -f


07参考资料

[1]OCI 镜像标准格式:  https://github.com/opencontainers/image-spec

[2]自校验的哈希树:  https://en.wikipedia.org/wiki/Merkle_tree

[3]FUSE:  FUSE — The Linux Kernel documentation

[4]virtiofs: virtiofs - shared file system for virtual machines

[5]runc 容器:  https://github.com/opencontainers/runc

[6]Kata 容器:  Kata Containers - Open Source Container Runtime Software | Kata Containers

[7]OSS 对象存储:  Object Storage Service (OSS)-alibabacloud

[8]Nydus-snapshotter:  https://github.com/containerd/nydus-snapshotter

[9]fuse-overlayfs:  https://github.com/containers/fuse-overlayfs

[10]5.19 版本: kernel/git/torvalds/linux.git - Linux kernel source tree

[11]对于容器镜像使用者: 容器技术之容器镜像篇

本周推荐阅读

Nydus —— 下一代容器镜像的探索实践

Nydus 镜像加速插件迁入 Containerd 旗下

cgo 机制 - 从 c 调用 go

从规模化平台工程实践&＃xff0c;我们学到了什么&＃xff1f;